1. Field of the Invention
The present invention relates to a Quality of Service (QoS) mechanism in an Internet Protocol (IP) network and to a method therefore.
2. Description of the Related Art
For many years, Internet had been built as a “best effort” network. In other words, no Quality of Service (QoS) was implemented in the network. More recently, QoS has become a need with the convergence of technology toward the use of Internet and its Internet Protocol (IP). Essentially, QoS aims at improving the performance of the network. In order to do so, a QoS mechanism applies a set of parameters to the traffic on the network. These parameters are linked to characteristics of the network that can be managed. Examples of such parameters include the allocated bandwidth, the delay of a network link, the end-to-end delay of a transmission, the delay-jitter or delay variation and the data loss probability. The QoS mechanism also enables subdivision of all available resources into a plurality of sub links with different levels of quality. Examples of available resources are the bandwidth of a given link or the processing power of a given node. This subdivision into the plurality pf sub links is particularly useful when different types of traffic travel on the same network. For example, downloading advertisement from the Internet may not request the same priority as live conferencing for an emergency surgery.
The efficiency of the QoS mechanism increases with the number of parameters that can be set on each one of the plurality of sub links. The measurement of the efficiency is done by a set of metrics mapped on the parameters. The QoS mechanism, which adds an overhead on the network, is always a compromise between the need for subdivision and control of the resources and the need for performance.
A few solutions were put forward in order to provide packet-switched IP networks with QoS. Examples of such solutions are Integrated Services (Int-Serv), Differentiated Services (Diff-Serv) and Multiple Protocol Label Switching (MPLS).
Reference is now to FIG. 1, which shows a signal flow chart of an Int-Serv path according to prior art. The Int-Serv architecture envisions per-flow resources reservations with the use of pre-determined paths in an IP network 100. It achieves that through Resource Reservation Protocol (RSVP) signaling [RFC 2205]. In that scenario, an entry node 110, handling a service flow with certain QoS restrictions, uses an RSVP PATH message 150 to request a path of resources from all intermediate nodes or routers 120 and 130 towards its projected destination. As an exit node 140 receives PATH message 154, it initiates a RESERVE message 160 that reserves the admitted path of resources across the nodes 120 and 130 that the PATH message 150, 152 and 154 traversed from the entry node 110 to the exit node 140. Subsequent traffic forwarding therefore should experience requested QoS guarantees as a result of resource reservation over the deterministic path.
However, as it is expected for the Internet to expand tremendously, there is a concern regarding the scalability of the hit-Serv architecture. Millions and millions of micro-flows are expected to pass across internal Internet nodes. It becomes a huge burden for those nodes to maintain information and consistently satisfy requirements of such an enormous number of flows.
As a second solution, the Diff-Serv architecture provides simple scalable differentiated forwarding of IP traffic. Each Diff-Serv node supports a finite number of forwarding categories in the form of Per-Hop Behavior (PHB) groups [RFC 2475]. All traffic that belongs to one forwarding category is treated exactly in the same manner independently of their actual end-to-end requirements. Since internal nodes only handle a limited number of forwarding categories, the architecture is, indeed, scalable.
In order to provide QoS, Diff-Serv envisions Service Level Provisioning or Service Level Agreement (SLA) with a neighboring network. FIG. 2A is a flow chart of a reception of a packet flow in an entry node implementing Differentiated Services (Diff-Serv). As the packet flow is received 210 in the entry node of the Diff-Serv network from the neighboring network, a forwarding category becomes associated with the packet flow (step 212). The packet flow is also conditioned (step 214) to remain consistent with the neighboring network's established SLA. For instance, some packets from the packet flow may be dropped if the maximum packet rate specified in the SLA is exceeded.
As it can be appreciated, Diff-Serv drives complexity and decision making towards the edges of the network while allowing simple scalable forwarding at intermediate nodes between the entry node and the exit node. Currently three PHB groups are defined. The Expedited Forwarding (EF) [RFC 2598] PHB group provides high guarantees by allocating resources for the maximum arrival rate of the aggregate. The Assured Forwarding (AF) [RFC 2597] PHB group provides assurance for high probability forwarding without any strict delay requirements. The Default (DE) group represents the traditional Internet “best effort” traffic.
The steps taken by an internal node in order to forward the packet flow to its next destination is shown in FIG. 2B. It is to be noted that, in regular working state, a plurality of packet flows with different associated forwarding categories concurrently travel in the Diff-Serv network. In order to forward the packet flows, the internal node has three packet queues, each one having an associated PHB group (EF, AF or DE). When one packet flow is received by the internal node with a given associated forwarding category, it is stored in the corresponding queue in sequence of arrival. The internal node, concurrently to the reception of new packet flows, forwards the content of the queue by first determining if the highest quality queue (EF) is empty (step 220). If the EF queue contains at least one packet, the internal node forwards the oldest packet of the highest quality queue (EF) (step 222) and returns to step 220. If the EF queue is empty, the internal node determines if the intermediate quality queue (AF) is empty (step 224). If the AF queue contains at least one packet, the internal node forwards the oldest packet of the intermediate quality queue (AF) (step 226) and returns to step 220. If the AF queue is empty, the internal node determines if the lowest quality queue (DE) is empty (step 228). If the DE queue contains at least one packet, the internal node forwards the oldest packet of the lowest quality queue (DE) (step 230) and returns to step 220. If the DE queue is empty as well, the internal node returns to step 220 and so on.
While Diff-Serv does achieve scalable networks, there are no strict QoS guarantees. With Diff-Serv nodes forwarding aggregate traffic, per flow reservation and therefore QoS guarantees are not possible. The architecture relies on the capability of the network to adequately manage its overall resources through conditioning actions in order to satisfy the agreed SLA. However, this is a very challenging task especially for large networks that rely on traditional routing where the path of traffic might be dynamic and unknown. Moreover, combined behavior of aggregate traffic from various neighboring networks cannot be anticipated even if all of them indeed lie within the bounds of their SLA. In order for a Diff-Serv network management to satisfy all SLA, sacrifices might become necessary in terms of network utilization to protect against worst case scenarios where all neighboring networks transmit at their maximum rates.
The third solution, MPLS [RFC 3031], aims at achieving fast and simple forwarding of IP traffic. In MPLS, routing information is signaled between neighboring nodes and a group of virtual paths known as Label Switched Paths (LSP) are established between the edges of the MPLS network. FIG. 3 shows an MPLS network 300 in which a packet flow 310 approaches the MPLS network 300 from a source 320 in order to reach a destination 330. The packet flow 310 is classified or labeled (step 332) by the MPLS network's entry node 110 onto an LSP that will adequately direct the packet flow 310 towards the exit node 140 and will also forward (step 333) the packet flow 310 toward the destination 330. Each MPLS node that participates in the LSP is known as a Label Switched Router (LSR) 325. Each LSR along the LSP has an incoming and outgoing labels binding that represent the routing information at each LSR 325 and indicate the forwarding direction as well as forwarding behavior to be applied to the packet flow 310. The incoming and outgoing labels for each LSR 325 therefore act as shorthand for routing and are pre-signaled between neighboring nodes through special protocols such as Label Distribution Protocol (LDP) [RFC 3036]. LSR 325 packet flow 310 forwarding (step 334) in that scenario becomes a simple label lookup and swapping (step 336) (change incoming to outgoing labels) operations rather than best prefix match as in traditional routing. When the packet flow 310 reaches the exit node 140 of the MPLS network 300, the packet flow is unlabelled (step 338) and forwarded (step 340) toward the destination 330.
Some extensions to existing routing protocols have been proposed to enable explicit routing in MPLS networks such as traffic engineering extensions to RSVP (RSVP-TE) and Constraint Routing LDP (CR-LDP). The main goal of explicit routing is to have only one destination for each entering packet bringing the logic of path establishment to the network's edges. Packets are classified at the edge into their explicit path and do not need to carry the explicit routing information as in traditional IP networks. Those extensions fill the objective of traffic engineering to avoid over-utilizing certain paths for traffic forwarding while other paths in the network remain under-utilized
While MPLS simplifies forwarding of IP data., it does not provide QoS. In fact, MPLS nodes do not take any QoS parameters into account for the forwarding of packets, but rather intepret each packet's label to forward it accordingly.
As it can be appreciated, none of the three presented solutions provides a scalable and efficient QoS mechanism for the Internet.
The present invention provides such a solution.